Natural Language Understanding (NLU) applications involve interactions between humans and machines. The interactions usually are controlled by the machine which asks questions of the users and attempts to determine the intended meaning from the user's answers (expressed in natural language) and then takes actions in response to these extracted meanings.
One important class of NLU applications is known as “call routing” which endeavors to semantically classify a telephone query from a customer to route it to the appropriate set of service agents or relevant specialized automatic system based on a brief spoken description of the customer's reason for the call. Call routing applications classify spoken inputs into a small set of categories for a particular application. Spoken inputs such as “I have a problem with my bill,” “Check my balance,” “Did you get my payment?” might all be mapped to a “Billing” category. Since people express these requests in many different ways, call routers are typically implemented as a statistical classifier which is trained on a labeled corpus—that is, a set of spoken requests and their classifications.
FIG. 1 illustrates the functional arrangement of a typical call routing system. Input speech from the caller is translated into a corresponding text string by an Automated Speech Recognition (ASR) Module 101. The ASR text is output into an NLU semantic classification component known as a Statistical Router 102. The Statistical Router 102 models the NLU task as a statistical classification problem in which the ASR text corresponding to an utterance is assigned to one or more of a set of predefined user intents, referred to as “call routes.” The Statistical Router 102 typically has an unacceptably high error rate (10-30% classification error rates are commonly reported in deployed applications), and thus a rejection mechanism is implemented to only retain those route hypotheses which are most likely to be correct. Therefore, another separate classifier—Confidence Engine (CE) 103—is used to produce confidence scores based on both acoustic and NLU features to determine the highest ranked N hypotheses (typically 3-5) output from the Statistical Router 102. A Route Reordering Component 104 then reorders the route hypotheses according to their overall confidence as determined by the CE 103. The best scoring route hypothesis is sent to Threshold Decision Module 105 which accepts the hypothesis if its confidence score is above an accept threshold. The value of the accept threshold is chosen so that the system satisfies one or more operating constraints such as an upper bound on the False Accept Rate (FAR) (typically 1-5%). Further discussion of an NLU-based statistical router system is set forth, for example, in U.S. Pat. No. 7,206,389,which is incorporated herein by reference.
To create a new call routing application, a new training corpus must initially be developed based on the specific needs of the new application. Different applications have different call routing classifiers based on their own specific needs. There is usually no simple many-to-one or one-to-many mapping from routers of one application to another. More specifically, the tags used to classify the collected user queries for any one given customer are redefined for each customer and there is no systematic reuse across different customers.
It has been proposed to pre-build call routers for a given vertical family of applications. That is, the classification tags for a given vertical domain might be pre-defined and then user query examples could be automatically classified with those vertical-dependent pre-defined query tags. This would allow deployment of bootstrapped call routers for that defined vertical domain. But one limitation of this vertical-silo approach is the failure to take into account that the boundaries between different verticals are not particularly well-defined, and in fact, many call queries actually appear in many different verticals, e.g., change-address, account-information, lost-bill, etc. In other words, the vertical-silo approach is limited to a given specific vertical and does not take advantage of the user query samples describing the same concept in other verticals.